Tricks of the Mac Game Programming Gurus/TricksOfTheMacGameProgrammingGurus.iso/Information/CSMP Digest/volume 1/csmp-v1-177.txt

Text File | 1994-12-08 | 46.5 KB | 1,213 lines | [TEXT/R*ch]

C.S.M.P. Digest             Mon, 05 Oct 92       Volume 1 : Issue 177

Today's Topics:

    How do you acess chooser username??
    MacINTERCOMM Invisible Xfers! (PR)
    Things That May Become Dim
    GDevices:  screenActive flag?
    reducing TCL project size
    faceless background app's.
    2 simple questions about locked blocks



The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  (This means you can't post questions to the
digest.)

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
cs.uoregon.edu).  Article threads are not added to the digest until the last
article added to the thread is at least one month old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The entire digest is available for anonymous ftp from ftp.cs.uoregon.edu
[128.223.8.8] in the directory /pub/mac/csmp-digest.  Be sure to read the
file /pub/mac/csmp-digest/README before downloading any files.  The most
recent issues are available from sumex-aim.stanford.edu [36.44.0.6] in the
directory /info-mac/digest/csmp.  If you don't have ftp capability, the sumex
archive has a mail server; send a message with the text '$MACarch help' (no
quotes) to [e-mail] for more information.

The digest is also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new issue as it is created.  Sorry, back issues
are not available through the mailing list.

Send administrative mail to [e-mail].


-------------------------------------------------------

From: [e-mail] (Michael S Shields)
Subject: How do you acess chooser username??
Date: 18 Jul 92 04:29:27 MDT
Organization: University of Utah CS Dept

How do you do this?? I can't seem to find even a mention of the chooser user-
name anywhere.(IM, Think Reference, Prog. Primer).  I know it can be done.

Thanks,
Mike



+++++++++++++++++++++++++++

From: [e-mail] (Thomas Insel)
Organization: University of Denver, Dept. of Math & Comp. Sci.
Date: Sat, 18 Jul 92 19:09:14 GMT

[e-mail] (Michael S Shields) writes:

>How do you do this?? I can't seem to find even a mention of the chooser user-
>name anywhere.(IM, Think Reference, Prog. Primer).  I know it can be done.

It's a STR resource somewhere in the System file.  I don't remember the
number, but you can set the username to something unique, then search
through the System w/ Resedit until you find it.
- --
Thomas Insel ([e-mail], [e-mail])

+++++++++++++++++++++++++++

From: [e-mail] (Philip Brandenberger)
Organization: Swarthmore College
Date: Sun, 19 Jul 1992 03:15:40 GMT

[e-mail] writes:
> [e-mail] (Michael S Shields) writes:
>
> >How do you do this?? I can't seem to find even a mention of the chooser user-
> >name anywhere.(IM, Think Reference, Prog. Primer).  I know it can be done.
>
> It's a STR resource somewhere in the System file.  I don't remember the
> number, but you can set the username to something unique, then search
> through the System w/ Resedit until you find it.
> --
> Thomas Insel ([e-mail], [e-mail])

'STR ' # -16096, but watch modifying it!  If you do, make sure
the name does not exceed 32 chars, that's 31 plus the length byte.

This is documented in IM Vol. VI, BTW.

- -Phil


- --
Philip J. Brandenberger
Swarthmore College, but I don't speak for it, in fact usually against it.
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Ed Swierk)
Date: 19 Jul 92 00:56:25 EDT
Organization: Cornell University

In article <[e-mail]>,
[e-mail] (Michael S Shields) writes:
> How do you do this?? I can't seem to find even a mention of the chooser user-
> name anywhere.(IM, Think Reference, Prog. Primer).  I know it can be done.

Check 'STR ' resource #-16096, found in the System file.

- --
                Ed Swierk
       Cornell University
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Michael Peirce)
Date: 19 Jul 92 19:41:17 GMT
Organization: Peirce Software


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Ed Swierk) writes:
> In article <[e-mail]>,
> [e-mail] (Michael S Shields) writes:
> > How do you do this?? I can't seem to find even a mention of the chooser user-
> > name anywhere.(IM, Think Reference, Prog. Primer).  I know it can be done.
>
> Check 'STR ' resource #-16096, found in the System file.

Right, but...

Remember that under System 7, there really isn't a Chooser Name any
more.  Rather there is an owner name and a machine name.

The owner name is stored in STR ID = -16096, the same as the old Chooser
Name.

The machine name is stored in STR ID = 16413.

The nature of your use of the Chooser name dictates if the new owner
name or the new machine name is most appropriate for you use.

Also remember that the owner name and machine name are not set in the
Chooser any more, but rather in the Sharing Setup Control Panel.  Using
the term "Chooser Name" will confuse users on System 7, they won't
have any idea of what you are talking about.

- --  Michael Peirce      --   [e-mail]
- --  Peirce Software     --   Suite 301, 719 Hibiscus Place
- --                      --   San Jose, California USA 95117
- --  Makers of...        --   voice: [phone] fax: [phone]
- --            SMOOTHIE  --   AppleLink: peirce & America Online: AFC Peirce

+++++++++++++++++++++++++++

From: [e-mail] (william bradley ward)
Date: 19 Jul 92 19:14:53 GMT
Organization: Colorado State University

Does anybody have, or know where I can get, a list of system resources -
ids and what they are?

Also, does anybody know how I can a change the string in the "About this Macintosh..." window that tells you what kind of machine you have?

Thanks,

Brad
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Michael Kistenmacher)
Date: 20 Jul 92 10:11:31 GMT
Organization: Blackbox Inc.


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Thomas Insel) writes:
>[e-mail] (Michael S Shields) writes:
>
>>How do you do this?? I can't seem to find even a mention of the chooser user-
>>name anywhere.(IM, Think Reference, Prog. Primer).  I know it can be done.
>
>It's a STR resource somewhere in the System file.  I don't remember the
>number, but you can set the username to something unique, then search
>through the System w/ Resedit until you find it.

Here you have some sample code from the Think C libraries. I hope
Symantec allows to post it.

- ----------cut------------

char *
getlogin(void)
{
    static char got_it, buf[33];
    short refnum;
    Handle h;

    if (!got_it) {
        refnum = CurResFile();
        UseResFile(0);
        h = GetResource('STR ', -16096);
        UseResFile(refnum);
        if (h) {
            HLock(h);
            sprintf(buf, "%#.*s", (int) sizeof buf - 1, *h);
            HUnlock(h);
        }
        got_it = 1;
    }
    return(buf[0] ? buf : NULL);
}

- ------------end---------------

- ---
- -----------------------------------
( Michael Kistenmacher / blackbox )
(  Germany  /  ++ 49 40 552 37 66 )
- -----------------------------------

+++++++++++++++++++++++++++

From: [e-mail] (Larry Meyer - mac weenie)
Date: 22 Jul 92 17:59:43 GMT
Organization: Xinet, Berkeley

In article <[e-mail]> [e-mail] writes:
>[e-mail] (Michael S Shields) writes:
>
>>How do you do this?? I can't seem to find even a mention of the chooser user-
>>name anywhere.(IM, Think Reference, Prog. Primer).  I know it can be done.
>
>It's a STR resource somewhere in the System file.  I don't remember the
>number, but you can set the username to something unique, then search
>through the System w/ Resedit until you find it.
>--
>Thomas Insel ([e-mail], [e-mail])

It's 'STR ' resource number -16096 in the System file; (I can't find the
documentation for this magic cookie).
- --
/*************************************************************
Larry Meyer Mac/Unix Programmer @ Xinet, Berkeley CA
[e-mail] (ask me about max<->unix stuff)
*************************************************************/

+++++++++++++++++++++++++++

From: [e-mail] (Elliotte Rusty Harold)
Date: 25 Jul 92 14:40:08 GMT
Organization: New Jersey Institute of Technology

In article <[e-mail]>, [e-mail] (Larry Meyer - mac weenie) writes:
> In article <[e-mail]> [e-mail] writes:
>>[e-mail] (Michael S Shields) writes:
>>
>>>How do you do this?? I can't seem to find even a mention of the chooser user-
>>>name anywhere.(IM, Think Reference, Prog. Primer).  I know it can be done.
>>
    Think C includes a function char* getlogin(void) intended to mimic the
Unix function getlogin.  It returns exactly what you're looking for, i.e. the
username set in the chooser desk accessory.  It's documented on p. 191 pf the
Standard Libraries reference in the Think C 4 manuals.  You'll need to
#include<unix.h> and either add the Unix library to your project or the
appropriate function from unixmisc.c to your source code.  This is all under
Think C 4.05.  Details may have changed under 5.0 but I imagine at least the
functionality is still there.

Elliotte Rusty Harold        Department of Applied Mathematics
[e-mail]        New Jersey Institute of Technology
[e-mail]        Newark, NJ 07103

---------------------------

From: [e-mail] (Peter Creath)
Subject: MacINTERCOMM Invisible Xfers! (PR)
Date: 20 Jul 92 11:43:13 GMT
Organization: Cube Technologies


In article <[e-mail]> (comp.sys.mac.comm), [e-mail] writes:
>
> MacIntercomm Delivers Invisible File Transfers
>
> Contact:
> Mercury Systems, Inc.
> Chad Laurendeau
> VP Operations
> 10000 Santa Monica Blvd. Suite 123
> Los Angeles, CA  90067
> [phone]
>
>
> LOS ANGELES, CA - July 6, 1992 P Mercury Systems today announced MacIntercomm,
> a full-featured multitasking telecommunications program that lets Macintosh
> computer users transfer files completely in the background even during the most
> intensive tasks.  The product will ship in August, 1992.
>
> MacIntercomm combines ease of use with power and flexibility never before
> thought possible on the Macintosh.  Its most exciting feature: true
> multitasking.  File transfers will no longer fail simply because the user is
> involved in a complex task in the foreground application.  MacIntercomm has the
> power to intelligently distribute processing power between applications.  This
> insures that it always gets just enough time to keep file transfers running at
> their fastest possible speed yet enables it to remain virtually invisible to
> other programs.   The result: no noticeable slowdown by either program.
>
> Existing programs in the communications market claim to run in the background,
> but if the foreground application is processor-intensive (such as a
> spreadsheet, compression program, database, or even a game), the file transfer
> will grind to a halt and usually fail.  Not so with MacIntercomm.
[rest deleted, see comp.sys.mac.comm]

Now how do they do that?  Take a look at SystemTicks() since last
resumeEvent and use a proportional amount of time before releasing
control?  And they claim this works on processor-intensive tasks.
Does that include a lengthy for...next loop where WaitNextEvent is
not called?  Does that include pulled down menus?

Inquiring minds want to know.  (Well, at least one inquiring mind
does.)

- ----------------------------------------------------------------------------
Peter Creath                 "When I was a boy I was told that anybody could
[e-mail]           become president; I'm beginning to believe it."
                                                           -- Clarence Darrow

+++++++++++++++++++++++++++

From: [e-mail]
Organization: Campus Computing Sites, University of Michigan-Ann Arbor
Date: Mon, 20 Jul 92 19:21:51 GMT

In article <[e-mail]> [e-mail] writes:
>
>In article <[e-mail]> (comp.sys.mac.comm), [e-mail] writes:
>>
>> MacIntercomm Delivers Invisible File Transfers
>>
>> Its most exciting feature: true
>> multitasking.  File transfers will no longer fail simply because the user is
>> involved in a complex task in the foreground application.  MacIntercomm has the
>> power to intelligently distribute processing power between applications.  This
>> insures that it always gets just enough time to keep file transfers running at
>> their fastest possible speed yet enables it to remain virtually invisible to
>> other programs.   The result: no noticeable slowdown by either program.
>>
>> Existing programs in the communications market claim to run in the background,
>> but if the foreground application is processor-intensive (such as a
>> spreadsheet, compression program, database, or even a game), the file transfer
>> will grind to a halt and usually fail.  Not so with MacIntercomm.
>[rest deleted, see comp.sys.mac.comm]
>
>Now how do they do that?  Take a look at SystemTicks() since last
>resumeEvent and use a proportional amount of time before releasing
>control?  And they claim this works on processor-intensive tasks.
>Does that include a lengthy for...next loop where WaitNextEvent is
>not called?  Does that include pulled down menus?
>
    They use two standard tricks and one new one.

    The most common ways of doing "real" background transfers is to use
a series chained completion routines as part of your async I/O - that way you
get called during interrupt time and can keep on processing.  Another common
trick, the MacIntercomm also does is to use VBL's to perform common interval
tasking.

    The "new trick" that they use is to write their own memory manager
so that they can do things like moving memory at interrupt time!!!  Yes, you
heard me correctly, they DO NOT use the Memory manager - they have written
their own as "Apple's is too inflexible for our needs".

NOTE: This information is based on a conversation with the lead engineer of
MacIntercomm, Frank Price.  Some of you may know Frank from his Hermes BBS.

- --
- -----------------------------------------------------------------------
Leonard Rosenthol          Internet: [e-mail]
Director of Advanced Technology   AppleLink: MACgician
Aladdin Systems, inc.          GEnie:     MACgician

+++++++++++++++++++++++++++

From: [e-mail] (Christoph Sold)
Organization: Universitaet Kaiserslautern
Date: Mon, 20 Jul 1992 20:13:01 GMT

In article <[e-mail]> [e-mail] (Peter Creath) writes:
>From: [e-mail] (Peter Creath)
>Subject: Re: MacINTERCOMM Invisible Xfers! (PR)
>Date: 20 Jul 92 11:43:13 GMT


>In article <[e-mail]> (comp.sys.mac.comm), [e-mail] writes:
>>
>> MacIntercomm Delivers Invisible File Transfers
>>
>> Contact:
>> Mercury Systems, Inc.
>> Chad Laurendeau
>> VP Operations
>> 10000 Santa Monica Blvd. Suite 123
>> Los Angeles, CA  90067
>> [phone]
>>
>>
>> LOS ANGELES, CA - July 6, 1992 P Mercury Systems today announced MacIntercomm,
>> a full-featured multitasking telecommunications program that lets Macintosh
>> computer users transfer files completely in the background even during the most
>> intensive tasks.  The product will ship in August, 1992.
>>
>> MacIntercomm combines ease of use with power and flexibility never before
>> thought possible on the Macintosh.  Its most exciting feature: true
>> multitasking.  File transfers will no longer fail simply because the user is
>> involved in a complex task in the foreground application.  MacIntercomm has the
>> power to intelligently distribute processing power between applications.  This
>> insures that it always gets just enough time to keep file transfers running at
>> their fastest possible speed yet enables it to remain virtually invisible to
>> other programs.   The result: no noticeable slowdown by either program.
>>
>> Existing programs in the communications market claim to run in the background,
>> but if the foreground application is processor-intensive (such as a
>> spreadsheet, compression program, database, or even a game), the file transfer
>> will grind to a halt and usually fail.  Not so with MacIntercomm.
>[rest deleted, see comp.sys.mac.comm]

>Now how do they do that?  Take a look at SystemTicks() since last
>resumeEvent and use a proportional amount of time before releasing
>control?  And they claim this works on processor-intensive tasks.
>Does that include a lengthy for...next loop where WaitNextEvent is
>not called?  Does that include pulled down menus?

>Inquiring minds want to know.  (Well, at least one inquiring mind
>does.)

>----------------------------------------------------------------------------
>Peter Creath                 "When I was a boy I was told that anybody could
>[e-mail]           become president; I'm beginning to believe it."
>                                                           -- Clarence Darrow


Given a lot of buffer memory, you can do amazing things at interrupt time...
But things get worse if the bufer overflows. :-(

- -Christoph


Christoph P. Sold                   CATS Software GmbH
                                    Mussbacher Landstr.2
                                    W-6730 Neustadt (Weinstrasse)
[e-mail]     Germany

"If an apple is fun, what the heck is an appletree?"

+++++++++++++++++++++++++++

From: [e-mail] (David Peterson)
Date: 21 Jul 92 04:51:38 GMT
Organization: University of Southern California, Los Angeles, CA


In article <[e-mail]>, [e-mail] (Christoph Sold) writes:
|>
|> Given a lot of buffer memory, you can do amazing things at interrupt time...
|> But things get worse if the bufer overflows. :-(
|>
|> -Christoph
|>

You don`t need to buffer the file transfer, just the options negotiation.
After you've decided what the file is named and where it is going, make all
subsequent read call asyncronous and have thier completion procs turn around
and do an asyncronous PBWrite and have its completion proc turn around and
to another asycronous read.

I've gotten this to work with MacTCP, I don't see why it won't work with
serial lines, ADSP, PPCToolbox, or anything else.

- -dave.

+++++++++++++++++++++++++++

From: [e-mail] (Jon W{tte)
Date: 21 Jul 92 22:15:23 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

> [e-mail] (David Peterson) writes:

   You don`t need to buffer the file transfer, just the options negotiation.
   After you've decided what the file is named and where it is going, make all
   subsequent read call asyncronous and have thier completion procs turn around
   and do an asyncronous PBWrite and have its completion proc turn around and
   to another asycronous read.

Wouldn't it be even faster if you did something like
queueing BOTH the next read and the next write from
the completion proc, and the the one that finishes
the latest of them queue the next read/write etc ?
This of course requires two buffers, but should be
quite doable and (theoretically, i.e. from one
floppy to another) be twice as fast !

- --
         Jon W{tte, Svartmangatan 18, S-111 29 Stockholm, Sweden

### You have the Easy Access virus. This virus may cause strange sounds
### and weird keyboard behaviour when you press the shift key repeatedly.

+++++++++++++++++++++++++++

From: [e-mail] (Jamie R. McCarthy)
Date: 21 Jul 92 22:12:47 GMT
Organization: Kalamazoo College

[e-mail] (Jon W{tte) writes:
>
>Wouldn't it be even faster if you did something like
>queueing BOTH the next read and the next write from
>the completion proc, and the the one that finishes
>the latest of them queue the next read/write etc ?

Ah yes (deep breath of fresh air)--this is exactly what we learned in
our File Structures class.  This is exactly what you should do!

>This of course requires two buffers, but should be
>quite doable and (theoretically, i.e. from one
>floppy to another) be twice as fast !

Aaaaaaaaahhhh (reality slams in)--everything I learned was _useless_!
When will we be able to heapsort without pausing during reads from
disk?  When will huge Mac database programs get to be anything but a
joke?  When will I be able to smoothly scroll my word processor while
the Finder makes a copy of my hard disk?  When will the IIfx (RIP)
get to _use_ its DMA circuitry?  When can I stop saying "but at least it
accesses the _floppies_ asynchronously"?

Alas (sobbing)--when O when will my IBM-programming friends stop
sniggering at my _totally_synchronous_ operating system?
- --
 Jamie McCarthy      Internet: [e-mail]      AppleLink: j.mccarthy
 He let the contents of the bottle do the thinking
 Can't shake the devil's hand and say you're only kidding            - TMBG

+++++++++++++++++++++++++++

From: [e-mail] (Harry Noel)
Date: Tue, 21 Jul 92 17:06:54 GMT
Organization: MCCS


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] writes:
> NOTE: This information is based on a conversation with the lead engineer of
> MacIntercomm, Frank Price.  Some of you may know Frank from his Hermes BBS.
>
> --
> -----------------------------------------------------------------------
> Leonard Rosenthol          Internet: [e-mail]
> Director of Advanced Technology   AppleLink: MACgician
> Aladdin Systems, inc.          GEnie:     MACgician
>


Well... As one who has seen first hand how he releases versions of
his software still containing the same bugs as the beta versions.
I would not bet the farm on this one.  He knew about 5 'major' bugs
in his package and released it anyway.  Two of which were security
related.

I won't waste time going into why he did it, but I you know a hermes
system who has been running hermes for a while, ask them about free
hermes upgrades....

- --------------------------------------------------
Harry Noel  -   grace!wtgdir![e-mail]
             or grace\!wtdir\![e-mail]
- --------------------------------------------------
"Murpy's Law is Recursive.
 Washing your car to make it rain doesn't work."

---------------------------

From: [e-mail] (P. Hawthorne)
Subject: Things That May Become Dim
Date: 22 Jul 92 11:16:16 GMT
Organization: Reed College, Portland OR

Pardon me if I seem naive about these issues, especially they have been
clarfied by System 7. I'm still trying to get a grip on the state of
Macintosh application programming as of System 6 <:-)

Is depending on the enableFlags of a MenuHandle asking for trouble? Say,
to disable all items in a single blow, or to find out swiftly whether any
commands are enabled?

If all of the commands in a menu are dimmed, should the menu's title on
the menu bar also be dimmed?

If a non-movable modal dialog is up, should all of the menu titles on the
menu bar be dimmed, since you can't use them? What if one of the menus is
hilited to begin with, such as the Apple menu after bringing up an about
window that goes away as soon as you click?

Should the menu bar be visible when the application has just been
launched and the splash screen is hanging out?

If a dialog window is deactivated, perhaps by the application being
suspended or another dialog coming up, should the dialog items be
dimmed?

 "DTS honestly reminds me of my first girlfriend's father..."
  Theus (Prometheus Hawthorne - Jones, [e-mail])

+++++++++++++++++++++++++++

From: [e-mail] (JohnC)
Organization: The Royal Society for Putting Things on Top of Other Things
Date: Wed, 22 Jul 1992 17:16:44 GMT

In article <[e-mail]> [e-mail] (P. Hawthorne) writes:
>Is depending on the enableFlags of a MenuHandle asking for trouble? Say,
>to disable all items in a single blow, or to find out swiftly whether any
>commands are enabled?

Since the menu definition procedure uses the enable flags to determine the
enabled-ness of an item, it's probably safe to use them.  Calling
_DisableItem with an item number of zero is defined to disable the entire
menu at once, overriding the individual item enable flags.  _EnableItem with
item zero removes this "override".  One note: there are only 31 possible
enable flags (plus one for the menu as a whole).  Any additional items are
defined to always be enabled.  Of course, if your menu has more than 31
items and is not a Font menu, something is wrong. :-)

>If all of the commands in a menu are dimmed, should the menu's title on
>the menu bar also be dimmed?

That's what the interface guidelines say, and it makes sense.

>If a non-movable modal dialog is up, should all of the menu titles on the
>menu bar be dimmed, since you can't use them? What if one of the menus is
>hilited to begin with, such as the Apple menu after bringing up an about
>window that goes away as soon as you click?

The guidelines say that menus and menu items that aren't available should be
dimmed.  Before System 7, you couldn't click anywhere outside a modal dialog
box, so it made sense to disable the entire menu bar.  Since System 7, Apple
recommends that the Apple, Edit and other system menus remain available during
modal dialogs.  I think the system handles this auto-magically for most cases.

>Should the menu bar be visible when the application has just been
>launched and the splash screen is hanging out?

I think that's up to the programmer.  I wouldn't show the menu bar until the
application was ready to interact with the user.

>If a dialog window is deactivated, perhaps by the application being
>suspended or another dialog coming up, should the dialog items be
>dimmed?

I think so.  You should certainly dim things that look different when
they're "inactive", such as scrollbars, text selections/insertion points,
and default button outlines.

- --
John Cavallino                  |  EMail: [e-mail]
University of Chicago Hospitals |         [e-mail]
Office of Facilities Management | USMail: 5841 S. Maryland Ave, MC 0953
B0 f++ c+ g++ k s++ e+ h- pv    |         Chicago, IL  60637

+++++++++++++++++++++++++++

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 25 Jul 92 06:32:50 GMT
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail] (JohnC) writes:
> In article <[e-mail]> [e-mail] (P. Hawthorne) writes:
>>If a non-movable modal dialog is up, should all of the menu titles on the
>>menu bar be dimmed, since you can't use them? What if one of the menus is
>>hilited to begin with, such as the Apple menu after bringing up an about
>>window that goes away as soon as you click?
>
> The guidelines say that menus and menu items that aren't available should be
> dimmed.  Before System 7, you couldn't click anywhere outside a modal dialog
> box, so it made sense to disable the entire menu bar.  Since System 7, Apple
> recommends that the Apple, Edit and other system menus remain available during
> modal dialogs.  I think the system handles this auto-magically for most cases.

I think the automagic only works if you use ModalDialog. I know I wrote some
code using IsDialogEvent/DialogSelect (because it was more convenient), and
I wasn't getting the special handling of the Edit menu; I changed the code
to call ModalDialog, and recoded my special item handling as a filter routine,
and cut/copy/paste then worked in my dialog.

Lawrence D'Oliveiro                       fone: [phone]
Computer Services Dept                     fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00

---------------------------

From: [e-mail] (Joe Francis)
Subject: GDevices:  screenActive flag?
Date: 23 Jul 92 16:27:03 GMT
Organization: Dartmouth College, Hanover, NH


What meaning does the screenActive flag have in GDevice record?  If I
wish to build a table of information about the available screens, and
use this info to decide where to display a graphic, should I be testing
this flag?

+++++++++++++++++++++++++++

From: [e-mail] (Jamie R. McCarthy)
Date: 23 Jul 92 19:02:00 GMT
Organization: Kalamazoo College

[e-mail] (Joe Francis) writes:
>
>What meaning does the screenActive flag have in GDevice record?  If I
>wish to build a table of information about the available screens, and
>use this info to decide where to display a graphic, should I be testing
>this flag?

Yes, you should be.  I don't know what it _means_ exactly, but you
shouldn't mess with inactive screens.
- --
 Jamie McCarthy      Internet: [e-mail]      AppleLink: j.mccarthy
 I'm having a lot of trouble seeing how a request that you "shut up" can be
 interpreted as "looking to other people for validation."      - Tim Pierce

---------------------------

From: [e-mail]
Subject: reducing TCL project size
Date: 23 Jul 92 17:45:27 GMT
Organization: VU Biology, Amsterdam, The Netherlands

I am starting on a project using Think C's TCL. After compiling the first
attempts I discovered that the project takes around 2 Megabytes of disk
space. I remember a discussion (I don't know if it was this news group)
where a method was given to reduce the size to around 1 Megabyte. Of course
I forgot to remember and/or save it. So can someone explain (again?) how it
works ?

Frank

+++++++++++++++++++++++++++

From: [e-mail] (Brian Hall)
Date: 24 Jul 92 06:46:50 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

[e-mail] writes:

>I am starting on a project using Think C's TCL. After compiling the first
>attempts I discovered that the project takes around 2 Megabytes of disk
>space. I remember a discussion (I don't know if it was this news group)
>where a method was given to reduce the size to around 1 Megabyte. Of course
>I forgot to remember and/or save it. So can someone explain (again?) how it
??~works ?

The cheezy answer is to always "compact and save" or turn on the
?t?"compact on save " option, and make sure you have debuggin
turned off (remove the marks next to each file).  A file with debuggin
on - even if the project itself is not being debugged at the moment-
takes up extra space for the debugging information.

- --

 \ | /   | Brian Hall                 [e-mail]
 - : -   | Mark/Space Softworks       Applelink: markspace
  /|\    |                            America Online: MarkSpace
 |-+-|   |
/-\|/-\  | People don't kill people, toasters kill people.

+++++++++++++++++++++++++++

From: [e-mail] (Andrew Gilmartin)
Date: 24 Jul 92 16:24:45 GMT
Organization: Brown University

In article <[e-mail]>, [e-mail]
wrote:

> I am starting on a project using Think C's TCL. After compiling the first
> attempts I discovered that the project takes around 2 Megabytes of disk
> space. I remember a discussion (I don't know if it was this news group)
> where a method was given to reduce the size to around 1 Megabyte. Of course
> I forgot to remember and/or save it. So can someone explain (again?) how it
> works ?

If you use a TCL precompiled header, your project files will be smaller.
For example, one of mine went from over 4M to under 2M. The TCL archive at
ftp.brown.edu has a .c file for creating a TCL precompiled header.
[ftp.brown.edu:/pub/tcl/misc/TCLDebugHeaders.misc.0]

- --
Andrew Gilmartin
Computing & Information Services
Brown University

[e-mail]
[phone]

---------------------------

From: [e-mail] (David Trefrey)
Subject: faceless background app's.
Organization: Adaptive Optics Associates
Date: Tue, 21 Jul 1992 16:45:46 GMT





    One of those little things that annoys me:

    People have been refering to certian types of background applications
    as 'faceless'.  What does 'faceless' mean??  I've done some
    background only stuff and it still appears in the finder's list.
    Does this mean it isn't faceless?  Or does faceless mean the program
    cannot produce a window?

                        thanks.
                            [e-mail]

- --

    David Trefry
    [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Francois Schiettecatte)
Date: 21 Jul 92 20:38:10 GMT
Organization: Johns Hopkins Univ. Welch Medical Library

Your last statement is correct, a faceless app has no user interface
whatsoever, there are no windows, menus, dialogs, etc, nor are you allowed
to even initialise those managers in a faceless app. A faceless app will
not appear on the finder list, but the memory it occupies will be added to
the system memory figure.

In article <[e-mail]> [e-mail] (David Trefrey) writes:
>
>
>
>
>    One of those little things that annoys me:
>
>    People have been refering to certian types of background applications
>    as 'faceless'.  What does 'faceless' mean??  I've done some
>    background only stuff and it still appears in the finder's list.
>    Does this mean it isn't faceless?  Or does faceless mean the program
>    cannot produce a window?
>
>                        thanks.
>                            [e-mail]
>
>--
>
>    David Trefry
>    [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (David A. Denboer)
Organization: University of Manitoba, Winnipeg, Canada
Date: Fri, 24 Jul 1992 02:39:33 GMT

Check Out  d e v e l o p  Issue #9
There is a good article in there about writing FBA's by C.K. Haun the author
of my favorite Tech Note #31 --> GestaltWaitNextEvent!

David A. denBoer
[e-mail]
Musi Computer Products
Macintosh Users Show Intelligence


---------------------------

From: [e-mail] (Jeffrey Verdegan)
Subject: 2 simple questions about locked blocks
Date: 10 Jul 92 18:30:16 GMT
Organization: U of Wisconsin-Madison College of Engineering

I have two questions about blocks of memory that have been locked with HLock.

1) I know a locked block is non relocatable and non-purgeable.  Does the non-
purgeable part only mean the the memory manager can't purge it to make room for
something else, or does it also mean I can't call DisposHandle for that block?
I would think that I can still call DisposHandle, but I'd like to know for sure.

2) Does every call to HLock have to be balanced by a call to HUnlock, or will a
single HUnlock unlock the block, regardless of how many times HLock was called
for that block?  If I remember correctly, it's the latter -- i.e. there's a
single bit that indicates the locked-ness (locked-ness monster? :-) ) of a
block, and therefore there is no counting of the number of times HLock was
called.  Can somebody confirm this please?

Thanks,
Jeff


- ----------

Jeff Verdegan
University of Wisconsin-Madison
Computer-Aided Engineering Center
[e-mail]
[phone]

+++++++++++++++++++++++++++

From: [e-mail] (Vince Vann)
Organization: University of Miami Medical School
Date: Fri, 10 Jul 1992 20:54:09 GMT

[e-mail] (Jeffrey Verdegan) writes:
>
>I have two questions about blocks of memory that have been locked with HLock.
>
>1) I know a locked block is non relocatable and non-purgeable.  Does the non-
>purgeable part only mean the the memory manager can't purge it to make room for
>something else, or does it also mean I can't call DisposHandle for that block?
>I would think that I can still call DisposHandle,but I'd like to know for sure.
>

You can dispose a handle with DisposHandle whether it is purgeable or not.

>2) Does every call to HLock have to be balanced by a call to HUnlock, or will a
> single HUnlock unlock the block, regardless of how many times HLock was called
> for that block?  If I remember correctly, it's the latter -- i.e. there's a
> single bit that indicates the locked-ness (locked-ness monster? :-) ) of a
> block, and therefore there is no counting of the number of times HLock was
> called.  Can somebody confirm this please?
>

The memory manager does NOT keep track of how many times you lock or
unlock a handle.  When you call HLock, the handle is locked immediately!
When you call HUnlock, the handle is unlocked immediately!!!

However, this does not mean than in your source code you should HLock
a block 10 times, and then HUnlock it once (or vice versa).

I suggest you always balance your calls to HLock/HUnlock.  It is good
practice, it makes sense, and it will save you a lot of debugging headaches!

> Thanks,
> Jeff
>

- --
Vincent R. Vann   <<<[e-mail]>>>
University of Miami School of Medicine, Miami, FL
- --

//////                  //////  __  //////                  //////
  //////              //////   /__)   //////              //////
    //////          //////    /  \      //////          //////

+++++++++++++++++++++++++++

From: [e-mail] (Keith Rollin)
Date: 11 Jul 92 22:39:23 GMT
Organization: Taligent

In article <[e-mail]>,
[e-mail] (Vince Vann) writes:
>
> [e-mail] (Jeffrey Verdegan) writes:
> >
> >I have two questions about blocks of memory that have been locked with HLock.
> >
> >1) I know a locked block is non relocatable and non-purgeable.  Does the non-
> >purgeable part only mean the the memory manager can't purge it to make room
for
> >something else, or does it also mean I can't call DisposHandle for that
block?
> >I would think that I can still call DisposHandle,but I'd like to know for
sure.
> >
>
> You can dispose a handle with DisposHandle whether it is purgeable or not.

Or whether it's locked or not. Or whether it's actually purged or not. However,
keep in mind that generally the only blocks that are marked purgeable are
resources (hmmm...what happens when you call DetachResource on a purgeable
resource? Is it still purgeable? I guess so). If you are dealing with purgeable
resources, you must call ReleaseResource, not DisposeHandle (<--- note the new
MPW 3.2 spelling). Only call DisposeHandle if you've called DetachResource.

>
> >2) Does every call to HLock have to be balanced by a call to HUnlock, or will
a
> > single HUnlock unlock the block, regardless of how many times HLock was
called
> > for that block?  If I remember correctly, it's the latter -- i.e. there's a
> > single bit that indicates the locked-ness (locked-ness monster? :-) ) of a
> > block, and therefore there is no counting of the number of times HLock was
> > called.  Can somebody confirm this please?
> >
>
> The memory manager does NOT keep track of how many times you lock or
> unlock a handle.  When you call HLock, the handle is locked immediately!
> When you call HUnlock, the handle is unlocked immediately!!!
>
> However, this does not mean than in your source code you should HLock
> a block 10 times, and then HUnlock it once (or vice versa).
>
> I suggest you always balance your calls to HLock/HUnlock.  It is good
> practice, it makes sense, and it will save you a lot of debugging headaches!

The standard practice in a black box environment is:

char oldState;

oldState = HGetState(myHandle);
HLock(myHandle);
MyRoutineThatNeedsALockedHandle(myHandle);
HSetState(myHandle, oldState);


- --
Keith Rollin
Phantom Programmer
Taligent, Inc.

+++++++++++++++++++++++++++

From: 9999cs02@uhdvx3 (Tina Marie!)
Organization: University of Houston-Downtown
Date: Sun, 12 Jul 1992 19:20:00 GMT

(Vince Vann) writes...
>[e-mail] (Jeffrey Verdegan) writes:
>>
>>2) Does every call to HLock have to be balanced by a call to HUnlock, or will a
>> single HUnlock unlock the block, regardless of how many times HLock was called
>> for that block?  If I remember correctly, it's the latter -- i.e. there's a
>> single bit that indicates the locked-ness (locked-ness monster? :-) ) of a
>> block, and therefore there is no counting of the number of times HLock was
>> called.  Can somebody confirm this please?
>>
>
>The memory manager does NOT keep track of how many times you lock or
>unlock a handle.  When you call HLock, the handle is locked immediately!
>When you call HUnlock, the handle is unlocked immediately!!!
>
>However, this does not mean than in your source code you should HLock
>a block 10 times, and then HUnlock it once (or vice versa).
>
>I suggest you always balance your calls to HLock/HUnlock.  It is good
>practice, it makes sense, and it will save you a lot of debugging headaches!
>

Or, there is always this method (the way I was taught to lock/unlock handles):

int DoNothing( Handle theHandle )
{
    SignedByte savedState;

    savedState = HGetState( theHandle );
    HLock( theHandle );

/*    Use theHandle */

    HSetState( theHandle, savedState );
}

This way, you always restore it to the state it was when you started.  If it
was unlocked, then it will be unlocked again.  If somebody else had locked it,
it is still locked.  This is a good idea if you have functions that nest,
both of which have a HLock/HUnlock in them.  When you return from the inner
function, the handle is unlocked, so if you use it again, there could be
problems.


ObQuestion:  Aren't there any other female Mac programmers on the net??

Tina Marie
Aspiring Mac Wizard
[e-mail]


+++++++++++++++++++++++++++

From: [e-mail] (Dave Newman)
Date: Sun, 12 Jul 92 11:43:32 PST
Organization: Notable Technologies, Inc.


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Jeffrey Verdegan) writes:
| I have two questions about blocks of memory that have been locked with HLock.
|
| 1) I know a locked block is non relocatable and non-purgeable.  Does the non-
| purgeable part only mean the the memory manager can't purge it to make room for
| something else, or does it also mean I can't call DisposHandle for that block?
| I would think that I can still call DisposHandle, but I'd like to know for sure.

The answer is yes, it's safe to call DisposHandle on a locked, locked
and non-purgeable, or a non-purgeable handle.


| 2) Does every call to HLock have to be balanced by a call to HUnlock, or will a
| single HUnlock unlock the block, regardless of how many times HLock was called
| for that block?  If I remember correctly, it's the latter -- i.e. there's a
| single bit that indicates the locked-ness (locked-ness monster? :-) ) of a
| block, and therefore there is no counting of the number of times HLock was
| called.  Can somebody confirm this please?

There is indeed no counting of the number of HLocks or HUnlocks on a
given handle. 3 HLocks can be undone with a single HUnlock. It is
recommended that you keep your locked blocks protected with HGetState
and HSetState calls. Failure to do so may cause a block to become
unlocked before it's safe to do so.

You typically use HGetState/HSetState when you have a function which
receives a handle as a parameter, and you're not certain whether the
caller has locked that handle or not. To be safe, you can record the
state of the handle with HGetState, then lock the handle yourself.
When done with the handle, you restore its previous state with
HSetState. Upon returning to the caller, it can then HUnlock the
handle if it was the function that locked it.

Final note: NEVER, N E V E R assume that just because it's safe to
HLock or HUnlock a handle multiple times that is therefore safe call
DisposHandle on the same handle multiple times.

Calling DisposHandle on the same handle multiple times will corrupt
the heap's private data structures. Your application will eventually
crash, and 999 times out of a 1000 it will be a seemingly mysterious
crash which happens at odd moments, rarely reproducible, and occuring
long after the actual double dispose on the handle.

- --Dave

- -----------------------------------------------------------
Dave Newman                 |  AOL:      AFC Tinman
Artillery Spotter           |  ALink:    TINMAN
Notable Technologies, Inc.  |  CIS:      70743,3323
Voice:    510.208.4449      |  internet: [e-mail]
FAX:      [phone]      |
- -----------------------------------------------------------

+++++++++++++++++++++++++++

From: [e-mail] (Tom Dowdy)
Date: 17 Jul 92 14:47:51 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>,
[e-mail] (Vince Vann) wrote:
> The memory manager does NOT keep track of how many times you lock or
> unlock a handle.  When you call HLock, the handle is locked immediately!
> When you call HUnlock, the handle is unlocked immediately!!!
>
> However, this does not mean than in your source code you should HLock
> a block 10 times, and then HUnlock it once (or vice versa).
>
> I suggest you always balance your calls to HLock/HUnlock.  It is good
> practice, it makes sense, and it will save you a lot of debugging headaches!

Well, if you go into a routine with the handle locked and you unlock it,
the routine that called you might be *very* surprised to see the handle
that it locked suddenly become unlocked.

When I'm writing large applications and I want to maintain "data hiding"
within various parts of the application, I never call HUnlock, instead
I do the following:
 HGetState(h, &flags);
 HLock(h);
 < fun stuff here >
 HSetState(h, flags);

This works great, although it is a bit more expensive than your simple
lock/unlock pairs.  However, because there are *so* few times when
locking a handle is really needed (DarkSide calls HLock 4 times, and
they are all on resources) - the overhead of this code is fairly minor.

When writing smaller and more localized applications (DarkSide comes to
mind
again), I usually just Lock/Unlock because I "know" what I'm doing.

 Tom Dowdy                 Internet:  [e-mail]
 Apple Computer MS:81KS    UUCP:      {sun,voder,amdahl,decwrl}!apple!dowdy
 20525 Mariani Ave         AppleLink: DOWDY1
 Cupertino, CA 95014
 "The 'Ooh-Ah' Bird is so called because it lays square eggs."

---------------------------

End of C.S.M.P. Digest
**********************